DRAFT — under teacher review.

Plan B Ready

The Hamilton and Alexandra College · Year 12 · 2026

Good designers expect things to go wrong. A planned mechanic turns out to be too hard to build in Godot. Scope creep means you now have five levels but none of them are finished. A plugin breaks two days before your submission. Markers at the top band are not looking for a perfect project — they are looking for evidence that you thought ahead and documented what you would do when things did not go to plan.

"Documents possible contingencies when developing solution designs · Documents possible solutions to mitigate issues."

Identify design risks

Start by reading through your detailed designs and asking: what could prevent this from working?

Every project has risks. The ones below come up regularly in Godot game projects.

Risk type	Example in a Godot project
Technical limitation	The shader or particle effect you designed is beyond your current Godot skill and cannot be built in time
Scope creep	You planned three levels and ten enemy types — now none of them are polished enough to submit
User misunderstanding	Playtesters cannot figure out the controls or game objective without explanation
Dependency failure	A Godot add-on or plugin is unsupported in your version and breaks your build
Client change	Your teacher or peer reviewer asks you to rethink a core mechanic after you have already built it

You do not need a risk for every row — two or three well-chosen risks that are genuinely specific to your design are worth more than a generic list.

Document contingency plans

A contingency plan is a specific, documented backup — not "I'll figure it out later". Vague intentions do not score marks. For each risk you identify, write down exactly what you will do instead.

Risk	Contingency
Drag-and-drop inventory mechanic is too complex to implement in Godot in time	Fall back to a numbered list with up/down arrow buttons — see mock-up B in the design log
Scope creep to five levels means none are complete	Cut to a vertical slice: one polished level with all core mechanics working rather than five rough ones
Godot inventory add-on breaks or is unsupported	Implement a simple custom Resource-based inventory using built-in Godot nodes only

Notice that each contingency names a specific alternative — a different design, a different node, a different scope. That specificity is what the performance descriptors reward.

Note

Contingencies are not admissions of failure. Documenting a backup plan shows that you understand your design well enough to know where it is fragile.

Show the backup designs

A contingency plan is stronger when you can point to something concrete — a second mock-up, an alternative pseudocode path, or even a rough sketch in your design log.

For example:

"If the drag-and-drop proves too complex, the fallback is a numbered list with up/down buttons — see mock-up B."

You do not need a fully polished alternative. A labelled wireframe or a short pseudocode snippet that shows the alternate logic is enough to demonstrate that you have actually thought the backup through.

Tip

There is a ready-made fillable table to organise your contingency plans: Plan B Contingency Table. Fill it in as you finalise your designs, not after submission.

Performance levels

Level	What it looks like
Basic	No contingencies documented — design assumes everything will work
Developing	Risks are identified but no solutions are offered ("this might be a problem")
Proficient	Possible contingencies are documented for identified risks
Strong	Specific, actionable backup solutions are documented — not just "I have a plan" but "here is the plan"

The jump from Proficient to Strong is the jump from naming a contingency to documenting a mitigation: a concrete design decision, a specific alternative, a referenced mock-up.

Quick checklist

At least two design contingencies documented (specific to your project)
Each contingency has a documented mitigation — not "I'll think about it"
Contingencies are specific to YOUR design, not generic
Backup designs are referenced or sketched in your design log

Check Your Understanding

1. Why does "I'll think of something" not score marks at the top band?

...

The performance descriptor says documents possible solutions to mitigate issues — documenting requires a specific, written plan, not an intention. A vague statement gives the marker nothing to assess and demonstrates no forward thinking about your design.

2. What is the difference between identifying a risk and documenting a mitigation?

...

Identifying a risk means naming something that could go wrong (e.g. "the shader might be too complex"). Documenting a mitigation means writing down a specific alternative you will implement instead (e.g. "if the shader is too complex, I will use a solid colour tint via a CanvasModulate node — see mock-up B"). One is observation; the other is a design decision.

3. Name one realistic risk for a Godot game project and write a specific contingency for it.

...

Example risk: art assets (character sprites and backgrounds) take longer to create than expected, leaving the game with placeholder squares at submission. Contingency: use free CC0 assets from itch.io or Kenney.nl (credited in the asset list) so that design and coding can continue without waiting on custom art. This is specific, actionable, and keeps the project moving.